This matches https://scancode-licensedb.aboutcode.org/markus-kuhn-license.html 👍🏻

This matches https://scancode-licensedb.aboutcode.org/efsl-2.0.html 👍🏻

Is this really correct? The license says "you are granted the right to create modifications", and the further restrictions only seem to apply to specifications or standards:

NOTWITHSTANDING THE FOREGOING, the creation or publication of derivative works of the Document or portions of the Document for use as a specification or standard is expressly prohibited.

So the logic here is that we catch the most onerous/limiting term in the license into the classification. The license has a term that prohibits modifications in some situations, so that should be recorded. It is not unusual that these packages do carry the actual specifications. Also the license text defines Document as:

By using the file or document that incorporates this License (the "Document"), you (the licensee) agree

So the prohibition could equally apply to some code. Regardless, we do not usually make distinctions between the types of content. If any content that could come with the license, may not be modified, then the "property:no-modifications" is/should be used.

There is some wiggle room here, we also have "modification-related-obligations", but that is normally used for (otherwise) open source licenses, which have obligations that relate to modifications that are more onerous than just marking of modifications.

In this particular case, this is a proprietary-free license, so it will be raised as a rule violation in Double Open Compliance in default cases anyhow, which in principle gives some further wiggle room. But I think this is quite clear.

So the logic here is that we catch the most onerous/limiting term in the license into the classification.

Ok, so we're being conservative here, makes sense.

If any content that could come with the license, may not be modified, then the "property:no-modifications" is/should be used.

But isn't it so that the question of modifications is tied to the use-case, not to the (code) content? I.e. it does not matter how you modify the code, but if you use your modifications as part of standards or specifications (in contrast to distributing the modified software otherwise), then you're not allow to to that.

Anyway, as the answer to that question is unrelated to the classification outcome because (as mentioned above) we use the most limiting term as the basis, I'll approve.